I veto against landing this until we at least petition the CSSLint folks to change the format of their .csslintrc file to be consistent with what jshint does, and what we implemented now. That format is much more sane and works nicely when moving from options to rc file or back: jquery/jquery-ui@39a2f46

I'll hold off on this until you've done so. Would you please /cc me on the issue you make over @ CSSLint?

@jzaefferer Have you pinged @stubbornella or @nzakas already?
I think the jshintrc style is definitely an improvement in readability, it might be overhead, but we could do a type checking of the csslintrc contents and pick the right parser.

Another thing is, if any of the editor plugin developers wrote its own implementation of a csslintrc parser instead of using the CSSLint internal stuff, they have to change it also. I'm totally behind the idea, but I think it will be a rocky road.

@stevenbenner
Nicely done PR (in fact much better than any PR I've ever done), will scan the code later this evening.

@jzaefferer @tkellen Any news on this?

If you guys are waiting for a resolution on getting CSSLint to support s JSON configuration file then I think that at the very least the existing JSON support implemented in this plugin should be removed because it is very unlikely that whatever spec CSSLint settles on will be the same as we find in the current version of this plugin.

When you search GitHub for .csslintrc you will find that there is a growing number of repositories that have implemented .csslintrc files with a spec that exists nowhere in the universe except for grunt-contrib-csslint.

Like it or not, it is important to understand that official grunt plugins (and jQuery UI which is using this plugin) have some serious clout in the JavaScript world and people assume that the way it's done in these repositories is the right way to do things.

@stevenbenner no news, no, except that Nicholas declared not being able to deal with CSSLint at all. It looks like the last commit from Nicole was in December and there were no commits for two months now. So expecting anything to change within CSSLint is pretty unrealistic at this point.

The SublimerLinter devs would also favor a JSON format that doesn't require a custom parser.

As for this comment:

whatever spec CSSLint settles on will be the same as we find in the current version of this plugin

You may be right, but I'd like to at least point out that this format is actually used by CSSLint itself. They don't support it for the .csslintrc file, but its exactly what the programmatic API uses. Which explains why there's very little code in the plugin to convert the format in use to what CSSLint expects.

Anyway, since CSSLint isn't moving anywhere, merging this PR is probably the sanest thing to do.

So, help me catch up. It seems that several people would like to change the way configuration is done in CSS Lint to match how it is done in JSHint, am I right? But doing so would mean we needed to parse json?

So, I can see the value in the former, how big a pain point is the latter?

Parsing and outputting JSON is trivial, since we can just use JSON.parse and JSON.stringify. The more interesting question then is how to actually structure the data. The format CSSLint uses internally has a key per rule and a value to set each rule to ignore, warn or error, like this:

{
  "qualified-headings": true,
  "unique-headings": true,
  "known-properties": false
}

The CLI arguments have lists of rules for each of these states, which this PR uses:

--ignore=box-model,ids,important
--warn=unique-headings

Switching to JSON could mean using that first format, or converting that second format to a JSON structure, for example like this:

{
  "ignore": ["box-model", "ids", "important"],
  "warn": ["unique-headings"]
}

The first format, which this plugin currently (incorrectly) uses matches the format used by JSHint as well as what CSSLint uses internally.

The last format is also what Scott suggested in his comment here. He even has a (trivial) patch to add JSON support in addition of the current format.

The rule key/value pair is a common pattern, and more human readable and versionable. +1 from me.

ping

merge conflict needs to be resolved.

@sindresorhus Are you pinging me?

I see that support for JSON config files just got added to CSSLint, and will be available in the next release. That probably makes this pull request redundant. But if you would like to add support for the old fashion config files I suppose I could revisit this.

@stevenbenner yes, just wanted to clean up some dormant prs. we'll wait for the new csslint release.